Release 10.1A: OpenEdge Development:
Progress Dynamics Repository Reference

gsm_status table — gsmst

This table lists the status of categories.

Table 14–3 lists the table’s FLA, fields, and foreign keys.

Table 14–3: gsm_status table information 

Table FLA	Fields (data type)	Foreign keys
gsmst	status_obj (Decimal) category_obj (Decimal) status_seq (Integer) status_tla (Character) status_short_desc (Character) status_description (Character) retain_status_history (Logical) system_owned (Logical) auto_display (Logical)	category_obj status_obj

Table 14–4 gives details of the table’s indexes.

Table 14–4: gsm_status index information 

Index name	Elements	Type
XPKgsm_status	status_obj	Primary Unique
XAK1gsm_status	category_obj status_seq	Unique
XAK2gsm_status	category_obj status_tla	Unique
XIE1gsm_status	category_obj status_description	Nonunique
XIE2gsm_status	category_obj status_short_desc	Nonunique

The valid status codes are set up in the gsm_category table. Table 14–5 gives examples of codes.

Table 14–5: Code examples 

Codes	Examples
Related entity mnemonic	GSMST for gsm_status
Category type	STS for Status
Category group	HST for History
Category subgroup	COD for Code

The category subgroup is the actual status in this case. The status categories are always system-owned and mandatory. The category mandatory flag indicates whether or not an object at this status can be modified.

At least one record must exist in this table for every category subgroup that has a related entity mnemonic of status (GSMST). The record is system-owned, has a sequence of 0, and cannot be deleted. It is always the default status for this category subgroup.

You can use this table to modify the narrative of a status and to add extra status levels within a category subgroup to represent your internal business processes.

From a business logic point of view, when a status changes within the same category, nothing needs to be done. The user can do this manually by a combo box. Changing status from one category to the next within a category group is usually done by a business logic process.

A join back to the gsm_category table determines what status an object is from a business logic point of view.

Entries on the gsm_status_history table determine the effective status of objects from specific dates. Therefore, the status does not need to be added to every table where it is used. For performance reasons in some cases, objects are linked directly to the gsm_status table to show the current status.